Architecture and Design
PCTO
Team Members
- Enrico Bragastini
- Loris Pesarin
- Davide Pizzoli
- Simone Tomelini
Table of Contents
- 1. Introduction
- 2. Design Goals
- 3. System Behavior
- 4. Use case view
Revision History
| Version | Modifier | Date | Description of Change |
|---|---|---|---|
| 1.0 | Enrico Bragastini | 17/04/20 | First version of the document |
1. Introduction
This document describes the architecture and design for the PCTO application being developed for the ITI Guglielmo Marconi. PCTO is a web application that allows teachers and students to check all the companies the school has relationships with in order to find the perfect one for an internship. The PCTO app has an overview of all the companies in the school's database and an interface to update the companies informations.
The purpose of this document is to describe the architecture and design of the PCTO application in a way that addresses the interests and concerns of all major stakeholders. For this application the major stakeholders are:
- Students and techers: the users
- Developers
- Project Manager
- Maintenance Programmers
2. Design Goals
There is no absolute measure for distinguishing between good and bad design. The value of a design depends on stakeholder priorities. For example, depending on the circumstances, an efficient design might be better than a maintainable one, or vise versa. Therefore, before presenting a design it is good practice to state the design priorities. The design that is offered will be judged according to how well it satisfies the stated priorities.
The priorities for the design that follows are:
- The design should minimize complexity and development effort.
- The design should take into account the development environment which is 6-7 small teams with complementary skills that work across time and space (teams are not co-located). Ideally the design should result in 6-7 loosely coupled components of equal size and complexity. If the components have well-defined interfaces each team can work independently coding to the interfaces of the other components. The concerns of each component should be narrow so that each team can specialize on a particular technology or skill.
- The design shouldn’t inhibit reusability. The two previous design goals are more important, but the ability to reuse components is also desirable.
3. System Behavior
The application has a homepage wich shows the user a brief overview of all the companies saved in the database. It lets the user to search over them to find a particular company. Then the application has another section that shows a company's data in detail. From that page it is also possible to change the company's data. The applications also provides a page used to insert a new company in the database. To access the companies data, the user is supposed to log in first.
For a more detailed account of software requirements, see the requirements document.
4. Use Case View
Basic Tour 1. Connecting to the application address using a browser 2. Log-in with the register credentials 3. Browse through the companies entries in the homepage 4. Find the one that suits you 5. Check that company's informations and contacts